你們正在討論一個新 App 的開發專案。

你在會議上問：「這個 App 的核心功能，需要後端團隊提供一組新的會員資料 API，請問這個時程上來得及嗎？」

後端團隊的技術主管阿德豪爽地拍了拍胸脯說：「這個 API 很單純啦！沒問題，交給我們！」

你心中一塊大石落地，在會議記錄上寫下「後端團隊負責搞定 API」，並對阿德投以感激的眼神。會議在大家一片「合作愉快」的氛圍中圓滿結束。

兩週後後，你的 App 前端功能已全部開發完成，就只等著串接那組神聖的 API。你興奮地在 Slack 上敲了阿德一下：「德哥！我們前端好了，可以準備串接 API 囉！」

頻道那頭，傳來了阿德困惑的貼圖，接著是一行字：「API？喔喔喔那個啊，我們上次有討論到，但它沒有被排入我們團隊這個季度的 Sprint Backlog 耶。我們手上還有 CTO 交辦的幾個更高優先級的任務，現在沒辦法處理喔。」

你的血液在那一刻彷彿凝固了。

你急忙翻出兩週前的會議記錄，上面確實寫著那一行字，但那又如何？那只是一份你自己的筆記，不是一張被正式建立、被指派、並被列入對方團隊工作排程的 Jira Ticket。

你看著交付專案項目時程，心裡想著，看來自己的明天也要跟那支還沒被寫出來的 API 一樣出現 404 Not Found 的錯誤了。

症狀診斷

這個病症，我們稱為「口頭承諾依賴症」。

病根在於，我們天真地相信，會議室裡的口頭共識，具有神聖不可侵犯的效力。我們誤把「當下的和諧」當成了「永恆的承諾」。

但真相是人類的記憶力極度不可靠（超級不可靠的那種 ☺️），而且還會被預算、績效、部門利益等現實因素，在大腦中進行「選擇性」的修改。一場沒有白紙黑字結論的會議，就像一場沒有公證人的登記結婚，當事人未來隨時可以否認自己說過「我願意」。

臨床案例

那天正好和設計師在工程師的電腦前看初版的遊戲介面成效，這時，業務主管剛好經過，看到我們聚在一起討論，也湊了過來。

「哇！這就是我們要上線的那個互動小遊戲嗎？看起來不錯喔！」業務主管顯得很興奮，然後突然指著螢幕說：「不過這個背景顏色太暗了，可以換成淺藍色嗎？還有這個按鈕位置應該放右下角，使用者比較容易點擊。最後是那個動畫的部分，我覺得需要調整成像是煙火的樣子，這樣會比較符合節慶感。」

我看向工程師，在他點頭確認後，回答：「可以啊，那我們就安排調整，在驗收會議的時候就會是新的版本。」

一週後，在正式的專案驗收會議上，我信心滿滿地展示專案的成果，結果最有趣的事情發生了，業務主管的臉非常嚴肅：「等等，這不是我要的效果。我記得我說的是淺綠色背景，按鈕應該要在中間才對。還有怎麼會是煙火呢？我們活動是在端午節不是雙十節，用煙火有點不太合適吧？」

我當下驚訝地看著他：「但是這個是你上週四經過時明確跟我們說要調整的….」

「我什麼時候說過？有會議記錄嗎？」業務主管一個反問，我當下啞口無言。

那只是一次走廊偶遇，我們沒有記錄任何東西，也沒有發送任何確認郵件，所以當然最後的結果可想而知，我們不得趕工加班，在兩天內重新調整畫面和功能，以符合最新的要求。

處方籤

這份處方，就如同「婚前協議書」。在任何專案或重要合作開始前，請務必和你的共事夥伴，共同簽署這份神聖的文件。

你不需要在每一次討論後，都寫出一份鉅細靡遺的報告。但一個專業的 PM 知道，根據會議的重要性，一份好的書面記錄，至少會包含以下模組的其中幾項，所以你可以根據當下的需求，挑選需要的模組做使用：

模組一：專案目的

• 適用時機： 新專案的啟動會議，或是第一次與新的利害關係人討論時。
• 核心問題： 我們為什麼要做這件事？它要解決什麼商業問題？

模組二：成功指標

• 適用時機： 當討論涉及專案目標或預期效益時。
• 推薦框架：OKR

模組三：範疇邊界

• 適用時機： 任何時候只要討論到具體的「功能」或「交付成果」時，都必須使用。
• 推薦框架： In/Out List 範圍內外清單，可以更聚焦在要什麼與不要什麼。
• 產出範例
  • 範圍內:
    • App 團隊： 開發註冊頁面 UI、前端互動邏輯。
    • 後端團隊： 提供會員資料讀取與寫入的 API。
  • 範圍外:
    • 不支援第三方社群帳號登入 (Facebook, Google)。
    • 後端 API 不包含用戶的歷史訂單資料。

模組四：關鍵角色與職責

• 適用時機： 只要會議結論涉及跨團隊合作或需要某人負責時，此為必備模組。
• 推薦框架： ARCI 責任矩陣
  • A - Accountable : 當責者 (ps. 最終背鍋俠，基本上通常只有 1 個)
  • R - Responsible : 負責執行者
  • C - Consulted : 事前諮詢者
  • I - Informed : 事後告知者
• 操作方式：
  1. 在會議中，確認每個關鍵任務，如「開發會員 API」、「設計註冊頁面」等
  2. 對每個任務，明確指定一位當責者 (A)，可有多位執行者 (R)
  3. 討論哪些人需要在決策前被諮詢 (C)，哪些人只需在事後被告知 (I)
  4. 製作責任矩陣表格，縱軸為任務，橫軸為角色/人名，在交叉處標記 A、R、C、I
  5. 分享給所有相關人員，確保大家對各自角色有共識
• 常見錯誤：
  1. 為單一任務指派多個 A (當責者) - 正確做法是每個任務僅有一個 A
  2. 過度使用 I (知會者) - 會造成資訊過載，反而會讓 I 沒有發生作用，因為過多、高頻率的資訊同步，反而會造成資訊疲乏而忽略。
  3. 未針對具體任務分配角色 - ARCI 是使用在具體的執行工作項目，不能放在那種無法「行動」、「籠統」的專案階段

模組五：時程與資源

• 適用時機： 只要會議結論涉及任何時間承諾或資源投入時，此為必備模組。
• 產出範例：
  • 里程碑 1： API 規格確認 (4/15 前)，需要後端團隊的小明投入 3 個工作天。
  • 里程碑 2： API 開發完成 (5/1 前)，需要後端團隊投入 2 位工程師共 10 個工作天。

B 計畫：當對方覺得「寫這個太官僚」時

好，我們來談談那個最常見的推託之詞。

如果你擬好文件，對方卻說：「哎呀，我們合作這麼久了，不用這麼正式啦！寫這個太官僚了！」

此刻可能真的無法要求對方，那麼你就必須要降低形式，但保留精髓，務必要整理、發出「會議結論與行動項目」資訊彙整，無論是主旨清晰的 email，或是在訊息中發送給所有與會者。

關於【XX專案】的會議結論與後續行動項目

嗨，各位，感謝今天寶貴的討論。
為了確保我們理解一致，快速總結一下今天的結論與後續的行動項目：

1. 專案目標 [簡述目標]
2. 關鍵決策 [條列1, 2, 3]
3. 行動項目

• **@王大明：**負責在 X 月 X 日前，提供客戶資料。
• **@陳小美：**負責研究資料庫的對接方案。

如果以上內容有任何誤解，請在今天下班前回覆，否則我們就以此作為共識繼續前進。

這個做法，叫做「被動式同意」。你沒有強迫對方簽字，但你創造了一份所有人都收到且「默認」的書面記錄，那麼這份資訊，就是你在未來不幸需要對質時，最有力的呈堂證供。

最後的醫囑

所以，下次當你在會議上聽到一句充滿善意的「沒問題！」時，請先別高興得太早。

一個沒有被寫下來的承諾，只是一陣風，吹過就沒了。

你的工作，不是去相信人性，而是去建立一個能保護所有人（包括你自己）免於「人性弱點」的專業流程。把事情寫下來，不是因為你不信任對方，恰恰相反，是為了幫助我們所有人，都能更輕鬆、更沒有爭議地，去兌現我們當初的信任。

當時第一次遇到需求方翻臉不認人時，我的心裡狀態：